Wendy E. Mackay

Designing interactive software is complex, requiring an understanding of human beings, software systems and the interaction between the two. Understanding people involves input from at least three social sciences. Psychology explores how the human sensory motor, perceptual and memory systems work, Sociology explores how people interact with each other, and Anthropology explores how people operate in the context of their daily activities. Developing interactive software also requires input from software engineering, including system architecture, programming languages, interaction techniques, as well as distributed computing and the use of a wide variety of hardware input and output devices. Creating innovative and aesthetically-pleasing designs requires input from trained designers, including graphic or interaction design and increasingly architecture and industrial design.

No single discipline provides all the necessary expertise: designing interactive software requires a multi-disciplinary approach. However, forming and managing multi-disciplinary teams has its own problems. Someone trained exclusively in one of the necessary disciplines is likely to interpret the design problem from within the framework of that discipline. This causes problems when people from different disciplines use the same words to mean different things or use different words to mean the same thing. As Djkstra-Erikson et al. [2] point out, "design" itself is a particularly troublesome word. Designers can only effectively communicate what they mean when they talk about the design of something: whether it is of the user experience, the screen layout, or the software architecture.

Another problem is that different disciplines place different values on different aspects of design. Scientists are trained to seek explanations of existing phenomena, engineers are trained to provide technical solutions to well-defined problems, and designers are trained to explore a design space and find solutions that "work". When people from these different backgrounds come together, they often run into conflicts due to their lack of a shared definition the problem.

Of course communication problems are not restricted to cross-disciplinary teams. For example, although research scientists share some common characteristics when compared to engineers or designers, when compared to each other, we also see different priorities research methods. An experimental Psychologist who runs laboratory experiments values reliability and precision in the data. An anthropologist who studies people in field settings values context and the validity of the data.

Designers too operate with different priorities. For example, if you ask a book designer, a video producer and a photographer to design the layout of a screen, they will choose different focal points of attention. A book designer is trained to emphasize text organised in a grid and "knows" that a reader will look for the most important information in the upper left-hand corner. A video producer understands the aspect ratio and visual quality of video and "knows" that the center of the screen is the hot spot. A photographer used to the flexible aspect ratio of film and the fine gradations in visual quality will consciously avoid the center and will placement of key items along diagonal across the screen. Of course, any individual designer will deviate from these design principles for any particular design. What is important to understand for us to understand is that these designers are starting from different underlying principles: when they break rules, they are breaking different rules. When these rules are not stated explicitly, other team members are likely to other designers processes and solutions.

Component Interaction Design Disciplines

If we are to teach people to successfully participate in multi-disciplinary design teams, we must go beyond the explicit content of each discipline. Students need to learn about the diverse underlying value systems of relevant disciplines and reflect upon how they interact at a meta level.

Figure 1 shows some of the different disciplines that contribute to effective interactive system design. The three primary contributors derive from the social sciences, computer engineering, and design. From the natural sciences, we commonly find contributions from experimental Psychology (usually Cognitive Psychology, but increasingly Ecological Psychology and Activity Theory), as well as Sociology, Anthropology (particularly Ethnomethodology) and Human Factors or Ergonomics. From these social sciences, we borrow research findings, such as how people perceive information or how human memory works, as well as research techniques, such as how to run controlled experiments or conduct observational studies in the field.

Designers who use research techniques from any of these scientific disciplines must distinguish between their use in a purely scientific context and as a resource to support design. The underlying assumptions surrounding how these techniques are used, and the goals of the research, may differ greatly.

For example, a usabilty study is not the same as a Psychology experiment. In experimental Psychology, the goal is to learn about fundamental characteristics of human beings, which exist independently of the experimenter. Controlled experiments are performed to test theories of human behavior, with the idea that they can be replicated by other researchers, who will then challenge or support the theory with further experiments. In contrast, usability studies are designed to evaluate particular software systems. Sometimes, the system is compared to another system, but the studies are rarely fully controlled in the scientific sense. The purpose is not to test theories of human behavior but rather to find problems with the system that was built and to test the adequacy of a particular design solution. Usability studies are rarely performed with the idea that they will be replicated and extended, but usually stand alone. A usability study is considered successful if it offers concrete information about the success of the particular system design for a particular set of users, but need not contribute the our general understanding of human beings.

Similarly, HCI professionals are careful to distinguish between ethnography and ethnomethodology[1]. The former consists of long-term observational studies of people in different contexts, ranging from anthropologists observing indigenous peoples in the bush to observing white collar professionals at work. Researchers attempt to describe behavior, seeking to identify general characteristics of human behavior as well as specific incidents of unique behavior. One of the roots of the word "ethnography" is "graph", which means "to write". Ethnographers, as scientists, are expected to contribute to a constantly-growing body of research literature, in which they compare and contrast their findings with those of other researchers.

Interactive system designers may profitably borrow observational techniques from ethnography, because they provide useful ways of observing and interpreting behavior in real-world contexts. However, the purpose is quite different. The designer uses ethnomethodology, i.e. methods from ethnography, to contribute understanding that is specific to the development of a particular software system. As with Psychology experiments, the particular techniques may be very similar but the context and underlying assumptions are quite different.

Engineering poses a different set of problems. One concern is that engineers are usually trained to solve problems that have been given to them and are evaluated on the technical validity of their solution, not the relevance of the problem. Yet designing a system by strictly following a set of design requirements does not guarantee a successful product. Human users add complexity and unpredictability to the situation and solutions that appear correct on paper may not be valid in practice. Software engineers are not taught strategies for questioning the design problem, so they often find themselves solving the wrong problems and ultimately failing to meet the needs of their users. Creating formal models of users and simulations of their activities provides a comforting feeling of having considered user's needs, until the software is actually used. Technical expertise is essential to the development of quality interactive software, but that technical expertise must be used to software the "right" problems.

The design disciplines, such as graphic design and architecture, represent the third critical component of interactive system design. Unlike engineers, designers are trained to question the 'design brief" and come up with alternative solutions. They have a very hands-on, apprentice-based learning process, in which they create designs for their portfolios, which are critiqued by faculty and fellow students. However, in many design schools, the needs of the user are not reflected in the design brief, or if they are, designers are given few tools to actually determine those needs. Designers must develop their own methods for finding out about users and are not taught strategies for objectively comparing design decisions.

Each discipline offers valuable skills and perspectives; each has the potential to miss important aspects of the design problem. Multi-disciplinary design teams offer a solution, covering the full spectrum of design approaches, taking advantage of the strengths offered by each discipline while mitigating potential blind spots. However such teams pose another problem: participants must be able to communicate effectively with each other. The next section describes some of the issues designers face when attempting to work in a multi-disciplinary design team.

Working in Multi-disciplinary Design Teams

In the previous section, I identified some of the characteristics of the disciplines that provide fundamental contributions to interactive system design. Each have long-standing academic and professional traditions, with different values and specific research or development techniques. When someone trained in one of these "traditional" disciplines begins to work on the design of interactive software, he or she is faced with a problem: how to reconcile the differences between what was learned and how it is applied in the new design context. Most social scientists aren't taught the differences between research studies in a scientific and a software design context: they must discover this on their own. Similarly, engineers often discover that the design requirements are a moving target and they have not been given strategies for successfully developing code in such a dynamic environment. Designers may also be frustrated, since their work is suddenly subject to different kinds of critiques and evaluation than they faced in design school.

As educators, we face the question of how to train people to become successful interaction designers. One strategy might be to try to develop expertise in all of the component disciplines, teaching scientific, engineering and design principles. However, it is unlikely that many individuals will become expert in everything: it is far more likely that individuals will show talent in one area. A gifted artist may be enjoy drawing and design but may find systematic observation of users or programming software to be difficult or uninteresting. Similarly, a trained observer of people may be able to contribute greatly to the understanding of the user's work, but may not be able to program or create elegant interface designs. A talented programmer may find talking to users or brainstorming interface design ideas equally difficult. So, while a few talented people may be able to contribute effectively in all areas, it is far more likely that they will find themselves contributing their expertise as part of a multi-disciplinary design team.

We have a different strategy, which is to continue training people from within their chosen major disciplines, whether scientific, engineering or design, but to increase their understanding and appreciation for the other disciplines. Students are exposed to different value systems and discuss how they may interact with each other.

Although ensuring that each person understands the perspectives of the others is important, it is rarely sufficient. We have found it necessary to create design activities in which all members of the design team, including users, can participate equally. These design techniques are borrowed from the full range of sub-disciplines and we discuss with students the implications of using them in a design, rather than their original, context. We choose techniques that increase communication among participants and we encourage students to develop new techniques that cross disciplinary boundaries.

Conclusion

Designing interactive systems requires diverse expertise, which is why most successful design teams are multi-disciplinary. Unfortunately, managing such teams can be difficult, because team members often do not communicate effectively with each another. When we teach interaction design, we address this problem explicitly, with a two-fold approach: First, we explain the value systems and some of the key assumptions from the component disciplines, including social sciences, engineering and design. Second, we teach hands-on techniques, often with video, that place team members (and users) on an equal footing when expressing design ideas. We want our students to understand and respect the contributions of others outside their discipline and to be able to use design techniques that allow all team members to actively participate, whether observing users, generating new ideas, prototyping systems or evaluating them.

In this first part, we presented the disciplines that serve as components of interaction design. The second part of this article describes some of these techniques, borrowed or inspired from various component disciplines described above.

Projet In Situ, Pole Commun de Recherche en Informatique du Plateau du Saclay, CNRS, Ecole Polytechnique, INRIA, Universite de Paris-Sud.